Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-066.TXT

Text File | 1992-06-03 | 104.5 KB | 2,532 lines

C.S.M.P. Digest             Thu, 30 Apr 92       Volume 1 : Issue 66

Today's Topics:

     Suggestion to the Developers of Think C


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (G. S. Marzot (Joe))
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 18:17:18 GMT
Organization: The MITRE Corporation

How about an editor which supports the OOP features. To steal a few ideas
from ACIUS' Object Master (which although quite nice is slanted more
toward MPW) single step Class and method creation and method overrides and
method deletion. It is often a pain to have to do all the book keeping of
classes twice, both in the header and source file.

I would also put in a purchase req. or two for Think C++.
Keep up the good work.

On the subject of compiler error logging - I say, what errors ;-)

-GSM


Email: [e-mail]

(standard  disclaimer)



- -------------------------

From: [e-mail] (Joe Francis)
Subject:  Suggestion to the Developers of Think C
Date: 1 Mar 92 01:25:13 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jeffrey Verdegan) writes:

> I agree 10^6% !!!!

Now... how did those operators bind again???

Is it (10^6)% ?

or (10%)^6 ?

:-P



- -------------------------

Organization: Penn State University
Date: Sunday, 1 Mar 1992 02:48:38 EST
From: Christopher Tate <[e-mail]>
Subject:  Suggestion to the Developers of Think C

In article <[e-mail]>, [e-mail]
(Brian Donnell) says:
>
>I am posting this suggestion for Think C for general perusal rather than
>sending it directly to Symantec so that other Think C users can add their
>two cents worth.  The voice of many users will have more impact.

Umm.  I'm not sure this is going to work, actually.  I suspect that if
everyone who responds to this article were to actually *mail* their
comments to Symantec, on real honest-to-God wood-pulp paper, there would
be a better response.  Remember, people like Phil Shapiro and Rich
Siegel read news on their own initiative; it's not a company function.

That said, I think that it's wonderful that a product has enough support
among its users that a post like this gets such a huge response!

>I think Think (:-)) C is one of the better programming environnments available
>on the market today.  With each release have come more improvements.  There
>are still things lacking (like C++ 2.1 conformance),

Okay; here's my first suggestion:  Don't bother with THINK C++.

(No, no; quiet back there!  Let me finish...)

Symantec has already acquired a C++ product, from a compiler developer
who's been giving Borland a run for its money for a lot of years in the
MS-DOS world -- not an insignificant feat.  Let Zortech run with its
C++ compiler.  They're the ones who *want* to do it, they have the
background for it, and the product already exists.  Sure, you might
want to work on getting its debugging environment up to speed with
THINK C's, but I don't see any need either to make THINK into what would
basically be a competing product, or to subsume the Zortech product into
THINK C.

Indeed; some people don't *want* C++.  I'm fully aware that that's a
heretical statement in some circles, but *expert* opinion is more divided
on C++ than many people realize.  Certainly it can be a powerful tool
for establishing maintainability or for designing a program structure,
but it's not really any "easier" to use OOP; it's a subtle skill that
some programmers are simply not comfortable with.  It's not their style.
And [he says, climbing out on a limb] it's not necessarily the "wave of
the future" that so many people (both well- and ill-informed) seem to
think.

>but I think the largest
>lacking feature is Think C's failure to report many types of errors/
>bad coding styles.  I would like to see Think C create a listing of warnings
>simliar to other compilers that includes things such as: unused variables,
>suspicious typecasts, using = where it looks like == should be used, and
>other things that are technically correct but may not be what the programmer
>truly intended.

'lint' can be a very useful tool, I agree.  I can certainly see this as
an option similar to the "Preprocess" or "Disassemble" menu items --
you'd command the compiler to give you a list of warnings and potential
coding errors, but this wouldn't be part of a normal compile cycle.

I'd *love* to have this sort of thing in a separate window, and rig
things such that double-clicking on a given warning line opens up the
corresponding source file and highlights the line in question.

>I would also like Think C to get way from this 'stop on the first error'
>nonsense.  Write it all out to a log file - so that I can leave a long
>compile unattended w/o being 99.999% sure that there will be no errors.

Actually, I don't mind this, because THINK C is *fast*.  I don't have
a problem with fixing every error in my source as I go; it makes me keep
my code clean, and do things right the first time around.  I *love* the
"Require Prototypes" option, for much the same reasons -- it keeps me
from making mistakes from the outset.

<Begin obligitory pedantic mode>

If it takes the compiler that much time to run into an error, then you
may really want to split the project into smaller files.  [I'll admit
that I'm a big fan of the "write a little bit, then compile it again to
see if it still works" approach to programming.  THINK C's speed makes
this possible.]

<End pedantic mode>

I remember hearing from someone in some sort of semi-official capacity
say that making THINK C try to compensate for errors and continue its
compilation would require a major rewrite, and would slow it down
significantly.  It's not worth it -- THINK C is just too damn fast; I
wouldn't want to hurt that.  Just look at how many people complained
when the global optimizer appeared, and slowed things down a bit.  And
THINK C 5 with the optimizer is *still* quite a bit faster than MPW,
let alone gcc.

Now, here are a few of my favorite suggestions:

The generated code *could* be better.  Global optimizations are a step
in the right direction, but there's still room for improvement.  This
came up about a month ago, regarding THINK's and MPW's use of the
DBxx instruction family.

I want disassembled code to have actual variable names instead of the
"0x0000(A5)" that it currently uses.  Just having the actual offsets
would be nice, instead of always using 0x0000.  Also, I don't see why
a file that's already been compiled has to be *recompiled* just to get
a disassembly.

I'd like to have some of the CMarker functionality built into the
editor -- especially the little menu to pull down that gives you a
list of all functions in the document, in order to jump to them.

Also for the editor, I'd like to see some sort of "command-arrow-key"
functionality that causes the screen to scroll right and left when the
cursor leaves the window, or causes the cursor to track with the page
up and page down keys.  I hate having to leave the keyboard to click in
the window once I've found the place that I want to edit....

I'd like to be able to edit generic text files without requiring a
project file to be open.

I'd *especially* like to search/replace in files that aren't in the
current project.

I want to be able to set the *default* font and size without ResEdit.

(Unlike some people, I *like* the THINK C editor.  The above are just
about the only gripes that I have about it.)

- -----
Christopher Tate     | Cryptogram #22:
[e-mail] |
[e-mail]  | CP VPY FJXU YBU FKNYJXU PI YBKVXKVT APMHNUWI
- -------------------| VUEUNNJHA.  YBU THJZUAJHCN JHU IMWW PI FUV QBP
Send me the answer!  | YBPMTBY YBUA EPMWC VPY LU HUDWJEUC.



- -------------------------

From: [e-mail]
Subject:  Suggestion to the Developers of Think C
Date: 1 Mar 92 17:19:25 GMT
Organization: COINS, UMass, Amherst

In article <[e-mail]>, [e-mail] (Paul Lucas) writes...
>    Since they now own the Zortech compiler, it should be easy to
>    fold it into the Think environment (which is a lot friendlier
>    than MPW, not to mention _lot's_ more inexpensive--MPW C++
>    withtout MacApp is $600).

Let's be realistic about combining two products, especially when they are
compilers.  Two completely different approaches are probably used in the
two, and I'd like to see Think C stay as fast as it is...

>    The upgrade price for 4.0 to 5.0 is too high (~$95); I'm not
>    going to upgrade again until Think C++ arrives, if ever.  (Do
>    you hear that, Symantec?  No more money until C++!)

There hasn't been any C++ 'features' that I have needed and haven't been able
to get along without.  C++ seriously munges programming style more and more,
especially letting you declare vars anywhere in your code (the reason for
putting them at the top of a fn was readibility, and boy is readibility
losing it in c++!).  If you don't like the $95 upgrade, go purchase MPW--
I'm sure you'll save money that route! ;)

>    If they wan't to keep a market, they have to give it what it
>    wants, not what they think is good for them.  The market wants
>    C++; it wants it yesterday.

Who is the market?  I don't need full C++.  If you are serious about OOP,
you'll be using SmallTalk or CLOS (real object systems) and not a language
that was force-fed object ideas.  The market wants better OOP development
tools, languages, etc.  C++ will probably go away, but I'm willing to bet
we'll see the next gereation of languages like CLOS for a long time yet.
Note: I am not a CLOS programmer; rather, I LOVE Think C (have for a long
time) and until OOP gets much simpler, I'll keep myself with as much control
as possible.
For everyone who wants more features, someone mentioned the key point: Think
C is what it is because of reduction of feature set to necessity.  Granted,
some added features would be useful, but the closer you try and push it
towards MPW, the more it slows down like MPW.  I'm sorry, but I worked with
MPW under C, C++, Pascal, and ASM all summer long, and it took me more time
getting MPW to do things the way I wanted, and sitting around for ungodly
amounts of time waiting for compiles.  If you need a 'I tell you once and
then you do everything for me' system (i.e., you grew up on and love Unix),
then that's great--more power to you.  The Mac's power is its simplicity.
Think C's power is also its simplicity.  So, I can't make fine-tuned Make
files.  I hate working with MPW for just that reason.  I'd rather do the one
or two things by hand and let Think take care of everything else.  MPW will
beat Think C on feature set because MPW is a full programmer's environment.
But, I'll bet you that I'll get a program running faster under Think C, and
with less bugs...
The entire Symantec Languages Group should be commended for their work.  They
are a tiny group for what they are handling, and they are effectively
competing against Apple (MPW)... not many others are.

Dave Chait
Chief Architect
Future Generation Software



- -------------------------

From: [e-mail] (Glenn Austin)
Subject:  Suggestion to the Developers of Think C
Date: Sun, 1 Mar 92 11:31:55 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jeffrey Verdegan) writes:
>
> In article <[e-mail]> [e-mail] (Brian Donnell) writes:
> >bad coding styles.  I would like to see Think C create a listing of warnings
> >
> >I would also like Think C to get way from this 'stop on the first error'
> >nonsense.  Write it all out to a log file - so that I can leave a long
> >compile unattended w/o being 99.999% sure that there will be no errors.
> >
> >What does everyone else think?
>
> I agree 10^6% !!!!

As long as you make it an OPTION -- I don't mind.  But, I don't want several
pages of error logs when all I forgot was a }.  Try it with MPW (or any
other C compiler) sometime.  Personally, THINK C is so quick, that, although
it is an annoyance, it doesn't take that long to watch it for a particular
file...

I agree, however, with the warning of unused variables -- it could fix bugs
where someone is allocating a ton of space on the stack with a variable
which is now unused, and then getting stack-heap collision errors at runtime...

===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================



- -------------------------

From: [e-mail] (Paul Lucas)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 03:07:07 GMT
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] writes:

>In article <[e-mail]>, [e-mail] (Paul Lucas) writes...
>>    Since they now own the Zortech compiler, it should be easy to
>>    fold it into the Think environment (which is a lot friendlier
>>    than MPW, not to mention _lot's_ more inexpensive--MPW C++
>>    withtout MacApp is $600).

>Let's be realistic about combining two products, especially when they are
>compilers.  Two completely different approaches are probably used in the
>two, and I'd like to see Think C stay as fast as it is...

    I would personally like to give them some credit and assume that
    they're smart enough to integrate the products.  By "fast" I
    assume you're referring to compile-times.  It's almost a
    non-issue; machines get faster and nobody buys your code because
    your compiler is fast, but on how good your code is.

>>    The upgrade price for 4.0 to 5.0 is too high (~$95); I'm not
>>    going to upgrade again until Think C++ arrives, if ever.  (Do
>>    you hear that, Symantec?  No more money until C++!)

>There hasn't been any C++ 'features' that I have needed and haven't been able
>to get along without.  C++ seriously munges programming style more and more,
>especially letting you declare vars anywhere in your code (the reason for
>putting them at the top of a fn was readibility, and boy is readibility
>losing it in c++!).  If you don't like the $95 upgrade, go purchase MPW--
>I'm sure you'll save money that route! ;)

    Then you haven't really tried to use C++.  No language makes
    programmers write "munged" programs--programmers write "munged"
    programs.  You can write truly awful, impossible-to-read, and
    nightmare-to-maintain programs in any language, C++ included.

    One of the reasons for lifting the declaration restriction was
    so that objects are initialized at the same time preventing
    uninitialized variable bugs.  Another reason, especially for
    constructed objects, is efficiency; declaring a variable at the
    top initializes it, and setting its value later initializes it
    again.

>>    If they wan't to keep a market, they have to give it what it
>>    wants, not what they think is good for them.  The market wants
>>    C++; it wants it yesterday.

>Who is the market?  I don't need full C++.  If you are serious about OOP,
>you'll be using SmallTalk or CLOS (real object systems) and not a language
>that was force-fed object ideas.  The market wants better OOP development
>tools, languages, etc.  C++ will probably go away, but I'm willing to bet
>we'll see the next gereation of languages like CLOS for a long time yet.
>Note: I am not a CLOS programmer; rather, I LOVE Think C (have for a long
>time) and until OOP gets much simpler, I'll keep myself with as much control
>as possible.

    If you've really been reading comp.lang.c++ and related
    newsgroups, there are always questions of the form "Where can I
    get C++ for my Mac?"

    Yes, I am serious about OOP, but big, hulking, nasty, army-of-
    programmers, production software isn't written in SmallTalk or
    CLOS.  C++ retains all of C's efficiency and only does the
    absolute minumum to implement the new features.

    This "discussion," which I would like to keep it, as opposed to
    a flame, is also really arguing apples and oranges: Think C (an
    implementation of C) and C++ (an entire language).  If the people
    at Symnatec wanted to, I'm confident that they could produce a
    full C++ compiler as simple and as fast as Think C.

>For everyone who wants more features, someone mentioned the key point: Think
>C is what it is because of reduction of feature set to necessity.  Granted,
>some added features would be useful, but the closer you try and push it
>towards MPW, the more it slows down like MPW.  I'm sorry, but I worked with
>MPW under C, C++, Pascal, and ASM all summer long, and it took me more time
>getting MPW to do things the way I wanted, and sitting around for ungodly
>amounts of time waiting for compiles.  If you need a 'I tell you once and
>then you do everything for me' system (i.e., you grew up on and love Unix),
>then that's great--more power to you.  The Mac's power is its simplicity.
>Think C's power is also its simplicity.  So, I can't make fine-tuned Make
>files.  I hate working with MPW for just that reason.  I'd rather do the one
>or two things by hand and let Think take care of everything else.  MPW will
>beat Think C on feature set because MPW is a full programmer's environment.
>But, I'll bet you that I'll get a program running faster under Think C, and
>with less bugs...

    Yes, I agree, but now that Think C has a foothold and a market,
    it's time for it to grow up.  Remember the 128K Mac?  It was a
    very-much watered-down Lisa.  The Lisa was too-much-tool
    quickly with a big price-tag ($10,000).  The Mac also made it
    because of the reduced feature-set.  Look at Macs now--all
    grown up: multitasking, 3 font technologies, knock-your-socks-
    off color, sound, etc.

    Also, remember the original Mac commercials?  Specifically, the
    one with an IBM PC on a desk and then the hulking user-manual
    crashing down next to it; then a Mac, will a thin booklet almost
    floating down next to it?  Of course, the situation is reversed
    when it comes to programming the thing (case in point: Inside
    Macintosh I-VI plus the technotes--end-to-end, it's about s foot
    thick).  In order to program the Mac (and even Apple has said
    this), you're going to need OOP.

>The entire Symantec Languages Group should be commended for their work.  They
>are a tiny group for what they are handling, and they are effectively
>competing against Apple (MPW)... not many others are.

    Yes, it's a great product--no argument.  Again, the other reason
    Think C made it is because it's also _lot's_ cheaper.
--
    - Paul J. Lucas                University of Illinois
      AT&T Bell Laboratories        at Urbana-Champaign
      Naperville, IL            [e-mail]



- -------------------------

From: [e-mail] (Andre "Just A Plumber" Srinivasan)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 02:40:00 GMT
Organization: Acme Plumbing Services And Exploding Cigars

) One other suggestion I have for Symantec is that they support the
) extended keyboard's special keys a little better.  Page up, down,
) home, etc. should move the cursor, not just the window...  Maybe
) having a key which would return to the last 'editing point' would make
) them feel better about changing this, but I think this would be an
) important change.

check out cmaster from jersey scientific.  its an add-on to think c
that makes the editing environment more usable by someone who is use
to a programmer's editor.

                                -andre

--
Andre Srinivasan  :     "This file provides programmers with information
734 LRDC          :     proving that it really was a hardware problem..."
U. of Pittsburgh  :
[e-mail] :                - MacsBug Ballon Help



- -------------------------

From: [e-mail] (Erik A. Johnson)
Subject:  Suggestion to the Developers of Think C
Organization: University of Illinois at Urbana
Date: Mon, 2 Mar 1992 07:31:59 GMT

[e-mail] (Andre "Just A Plumber" Srinivasan) writes:
>) One other suggestion I have for Symantec is that they support the
>) extended keyboard's special keys a little better.  Page up, down,
>) home, etc. should move the cursor, not just the window...  Maybe
>) having a key which would return to the last 'editing point' would make
>) them feel better about changing this, but I think this would be an
>) important change.
>
>check out cmaster from jersey scientific.  its an add-on to think c
>that makes the editing environment more usable by someone who is use
>to a programmer's editor.

I agree completely!  Many of the "I want _________ in the THINK C editor"
that I've seen in this thread are available in cmaster.  (For those of
you who are familiar with the old cmarker, that gave you a pop-up menu
of all the function in your program by command-clicking in the window's
title bar -- cmaster is the next generation, including cmarker's abilities
and a lot more.)

They have an applelink address: [e-mail]

(Standard disclaimer -- I have no connection with jersey scientific other
than being a very happy user of cmaster.)


Erik A. Johnson        \    Internet: [e-mail]     \       |
- ----------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \



- -------------------------

From: [e-mail]
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 04:21:28 GMT
Organization: COINS, UMass, Amherst

In article <[e-mail]>, [e-mail] (Paul Lucas) writes...
>    Yes, it's a great product--no argument.  Again, the other reason
>    Think C made it is because it's also _lot's_ cheaper.

Well, maybe you just made the key point.  It is still faster, it is still
simpler, and hey, it's still cheaper.  Anyone want to wager on how much
the Think C being envisioned would cost?  Me, I'm a college student with no
money.  I've worked for companies who had the money to throw around and could
purchase the entire MPW set for every programmer.  I broke into a sweat simply
finding out how much the basic shell costs.  If I want that much power and
flexibility, I'd probably want a real OS too, so let's scrap the Mac and
go unix (note the <GRIN>)...

Dave Chait
Chief Architect
Future Generation Software
"Anyone want to hire a recent grad? What's that? You don't hire recent grads?"



- -------------------------

From: [e-mail] (Brent)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 14:32:00 GMT
Organization: Texas A&M Univ., Inc.

[e-mail] (Brian Donnell) writes:
| [more warnings to be printed desired]

What I would like to see is a cross-referencing option.  5.0 has the
"Create Link Map" option which is helpful for finding variable locations
in the compiled code, but what about finding them in the source code?
The Find... command works great, but a nice full-fledged cross
reference would be extremely nice and not much more code to implement.
Think C already tells you where variables/functions are referenced
if the link fails.

Cross Reference format:
IDENTIFIER  (FILE.C)  4* 5 20 30 40 50
            (foo.c)  24   48   76
i.e., for each identifier, print the file(s) it is referenced in (which
think C already keeps track of) and the line numbers on which it is
referenced with the variable definition line # having the asterisk.

|I would also like Think C to get way from this 'stop on the first error'
|nonsense.  Write it all out to a log file - so that I can leave a long
|compile unattended w/o being 99.999% sure that there will be no errors.

I definitely agree with Brian on this point.  That is the one "feature"
of Think C that I truly hate.  I'm taking a compiler design course now
and I am writing a Pascal subset compiler as the semester project (it's coming
along nicely).  One of the issues is that compilers are not only to
compile the code, but also be helpful to the programmer.  The compiler
is a tool to manipulate source code.  Think C needs to be more flexible
in it's error handling so that, as Brian said, we (programmers) do not
have to be 99.999% sure that it will work.  A logfile would be a great
asset to Think C.

A logfile would free programmers from the "let's find the next error
and recompile" methodology/rut that Think C FORCES us into.

-Brent "Save us from the madness!" Burton
--
- ----------------------------------------------------------------------------
Brent P. Burton, N5VMG                                    Computer Sci/Physics
[e-mail]                                   Texas A&M University
- ----------------------------------------------------------------------------



- -------------------------

From: [e-mail] (Francis H. Schiffer 3rd)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 15:10:55 GMT
Organization: ST ScI/SESD

In article <[e-mail]>, [e-mail] (Jeffrey Verdegan) writes:
>
> In article <[e-mail]> [e-mail] (Brian Donnell) writes:
> >bad coding styles.  I would like to see Think C create a listing of warnings
> >
> >I would also like Think C to get way from this 'stop on the first error'
> >nonsense.  Write it all out to a log file - so that I can leave a long
> >compile unattended w/o being 99.999% sure that there will be no errors.
> >
> >What does everyone else think?
>
> I agree 10^6% !!!!

Gee, am I the only Think C programmer that uses the Check Syntax command?
I generally check each module as I write/modify it and so usually have a better
than 99% chance that the full compile will run without error.  I _like_ the
ability to code/compile/test a little.  I do agree that a Lint function would
be much appreciated, maybe implemented in the same manner as the current
precompile function.

- -----------------------------------------------------------------------
Francis H. Schiffer 3rd    [e-mail] | - Any opinions are mine -
[e-mail]       stscic::schiffer | Not a programmer, just a
[e-mail]   iuegtc::schiffer |    user who programs
- -----------------------------------------------------------------------



- -------------------------

From: [e-mail] (Bill Leue)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 16:34:43 GMT
Organization: General Electric Research & Development


Sorry if I'm repeating what others have already said; I'm coming into this discussion
in the middle.

My current wishlist includes:

a) Symbolic addresses in disassembled code listing.  WHY does the current
disassembler only include numeric offsets for variables?!?  After all, the
disassembler presumably has the symbol table available for reference. Doesn't
it make a lot more sense for the computer to do the translation from numeric
offsets to variables than for us to spend hours groveling over the code?

b) More stability and better documentation on internal errors.  I wasted a whole
day trying to cure an "Internal Error (ZREF) - Remove all Object Files" error.
Not only is this error (and other internal errors) completely undocumented, but
removing the object files doesn't help.  The only cure I could find was to
trash and rebuild the project file.  What's even worse is that the reason that
the project file got corrupted in the first place is that I killed a compile
with a "Command-.".  This seems to be a guaranteed way of clobbering your
project file.

c) A better debugger, particularly some ability to help when you get an
unexpected error such as a Bus error or address error.  Just dumping the PC
isn't really too helpful.  How about position the cursor at or near the
offending line of code?

-Bill Leue
[e-mail]




- -------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 16:45:57 GMT
Organization: Computer Aided Engineering, Univ. of Wisconsin-Madison

I guess I was a little hasty in my enthusiastic support of getting rid of the
"stop on every error" feature.  Making it an option would definitely be cool.

A lot of people have alluded to the fact that one of THINK's greatest advantages
is its speed, and claimed that features such as continuing upon finding an
error or generating warnings would slow it down.  I'm surprised we haven't heard
from Rich Siegel or Phil Shapiro on this one.  So, how 'bout it guys?  Would
such additions sacrifice some core aspect of TC that is key to its speed?  Or
is that area classified?

As long as we're wishing, I love the Disassemble feature, but call me lazy, it
would be rilly rilly nice if it would show me which line of C source generated
each line of Assembly.  I seem to remember reading recently about such a
goody for MPW.


Jeff


- --------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]



- -------------------------

From: [e-mail] (Brian Donnell)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 16:40:30 GMT
Organization: NASA/JSC

In article <[e-mail]>, [e-mail] (Christopher Tate) writes:
>
> <Begin obligitory pedantic mode>
>
> If it takes the compiler that much time to run into an error, then you
> may really want to split the project into smaller files.  [I'll admit
> that I'm a big fan of the "write a little bit, then compile it again to
> see if it still works" approach to programming.  THINK C's speed makes
> this possible.]
>
> <End pedantic mode>
>

Splitting the project into smaller files does not solve the problem, for Think
C stops the entire "make" at the first file where the first error occurs.
Even considering the arguments that others have made about the effects of
on the speed of compilation made by error recovery, Think C could at least
try every file on a make so that I could see the first error from every file.
What if I'm compiling 100 modules and there are no errors except on line 100
of the third one?  I walk away expecting the compile to take about 30 minutes
(pretty good - Think C wins high marks)...but come back to discover it failed
after a minute and a half.  Grrr.

Actually - after reading the plethora of responses (geez :-)), I agree that
a separate 'lint' like utility would be a better approach than integrating
it directly with the compiler and thus sacrificing that beautiful race-car
effect.

I guess I'm up to $0.04 now... :-)

Brian Donnell
NASA/JSC



- -------------------------

From: [e-mail] (Joe Francis)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 18:55:13 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] writes:

> >    If they wan't to keep a market, they have to give it what it
> >    wants, not what they think is good for them.  The market wants
> >    C++; it wants it yesterday.  [Paul Lucas]

> Who is the market?  I don't need full C++.  If you are serious about OOP,
> you'll be using SmallTalk or CLOS (real object systems) and not a language
> that was force-fed object ideas.  The market wants better OOP development
> tools, languages, etc.  C++ will probably go away, but I'm willing to bet
> we'll see the next gereation of languages like CLOS for a long time yet.
[[e-mail]]

The market is Paul Lucas, and myself, and a host of other mac software
developers.  You are incorrect about what many OOP programmers want.
Many want an OOP development environment that:
1) doesn't get OOP in their way when they don't need it.
2) gives them reasonable execution and code size.
3) let's you create standalone mac applications.
4) generates object that a mere mortal can follow in macsbug.
5) was here yesterday - strike that: was here last year.
Guess what?  Think C and MPW C++ are the two answers to those
questions.  Not SmallTalk.  I know; I bought DigiTalk's product because
their advertising failed to mention that you could not create
standalone mac apps.  Now, years later, they can do it (for an upgrade
fee of course).  In the meantime, I've actually accomplished something
useful with MPW C++.

You can say C++ was force fed objects.  Or you can say that SmallTalk
was stripped of the fundamentals.  I know which is better for my needs.



- -------------------------

From: [e-mail]
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 19:25:03 GMT
Organization: COINS, UMass, Amherst

In article <[e-mail]>, [e-mail] (Brent) writes...
>I definitely agree with Brian on this point.  That is the one "feature"
>of Think C that I truly hate.  I'm taking a compiler design course now
>. . . .
>A logfile would free programmers from the "let's find the next error
>and recompile" methodology/rut that Think C FORCES us into.

I have to disagree with Bren on this point for the same reason that has been
pointed up numerous times: having it stop is advantageous in most cases.
One thing I always hated about MPW was letting it compile for ten minutes, only
to find some hundred errors, all cascading off of one or two minor problems.
Logfiles do not IMHO make programming easier, it just forces you to compile
the whole darn file before finding out what's wrong.  If anything, I program
faster in Think C because of the quick find-and-fix-error system.

And to Brian: I don't normally have 100 files to recompile, because I'm working
error by error, rather than making changes to 100 files and seeing if they
worked out correctly.  I really think I get my code up and running faster
because of it...

I will agree with one point: we're at least up to $.04 if not more! ;)

Dave Chait
Chief Architect
Future Generation Software



- -------------------------

From: [e-mail] (Michael Hecht)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 19:45:43 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>,
 [e-mail] (Christopher Tate) writes:
>
>In article <[e-mail]>,
> [e-mail] (Brian Donnell) says:
> >
> >I would like to see Think C create a listing of warnings similar to other
> >compilers that includes things such as: unused variables, [...]

I'd like to go a step further and have THINK C generate a complete link
map for me. It would include all references to functions, statics, globals,
and autos. This would not only let me track down unused variables, but it
would assist me in determining call tree dependencies, so I know what code
is going to break when I change a parameter, etc. THINK C 5.0 adds the
segment map, which is good, but that's not what I'm talking about here.

>
> >I would also like Think C to get way from this 'stop on the first error'
> >nonsense.  Write it all out to a log file - so that I can leave a long
> >compile unattended w/o being 99.999% sure that there will be no errors.
>
> I remember hearing from someone in some sort of semi-official capacity
> say that making THINK C try to compensate for errors and continue its
> compilation would require a major rewrite, and would slow it down
> significantly.

Yes, but how about this--instead of listing all errors found in each
source file, how about only listing the FIRST error in a source file,
stopping its compilation, then moving on to the next source file? If the
error occurs in a header file, then, of course, there's no need to compile
any other files that also include that header. This shouldn't require
major structural changes to the compiler.

I agree with you that the "stop on first error" behavior is quite acceptable
(and preferred!) when you're in a tight development cycle, but when I change
a bunch of source and want it to compile 100 files while I'm at lunch, I get
real aggravated when I return to find that it stopped on the first one
because of a missing semicolon or such.

> I want disassembled code to have actual variable names instead of the
> "0x0000(A5)" that it currently uses.  Just having the actual offsets
> would be nice, instead of always using 0x0000.  Also, I don't see why
> a file that's already been compiled has to be *recompiled* just to get
> a disassembly.

I agree that the disassembly could be nicer. Variable names or offsets
would be good. Embedded source code would be even better. I heard Phil
Shapiro speak about this a few months ago, and he said that the disassembly
feature is mostly a hack--it's done after code generation and optimization,
not during. Now admittedly, it would be difficult to match up instructions
to source at this point (especially after global optimizations), UNLESS
you have debugging information available. The debugger knows how to find
a line of source from a code offset, so it stands to reason that this
information could be used by Disassemble, if the file has been compiled with
debugging enabled. Or, for that matter, since Disassemble always recompiles
the code anyway, it could "pretend" that debugging was enabled even if it
wasn't.


As for the rest of my wish list:

*  Support for multi-programmer projects, including code check-in, check-out.
   "Projector-aware" just doesn't cut it. I bought THINK C so I wouldn't need
   MPW. A multi-programmer software license should go with it, of course.

*  The features of THINK Back (great hack, Phil!) incorporated into THINK C.
   Also make "Use Disk" backgroundable.

*  The ability to manipulate project files in groups--moving to different
   segments, deleting, moving from "project" tree to <system> tree, etc.


All of the items mentioned so far in this thread were brought up two years
ago at a Symantec languages forum at the WWDC. Most of them were brought up
again at a similar forum that Symantec hosted at January's MacWorld Expo.
Shapiro said it was the same old story of too much work and too few resources.
I develop software too, and I suspect that part of the story is something
that's happened to projects I've worked on: a reluctance to fix the old, and
a preference to work on the new (global optimization, OOP). After all, new
stuff is more exciting! The press doesn't help any; they only want to publish
new feature scorecards.

But I've found that sometimes you just have to ignore the press and your own
preferences and really listen to the users' requests to smooth out those
rough edges. I think the overwhelming response to the original poster shows
that Symantec should really think seriously about ironing out these last few
rough edges.

--Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT



- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 21:06:56 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

>> If they [Symantec] want to keep a market, they have to give it what it
>> wants, not what they think is good for them.  The market wants
>> C++; it wants it yesterday.

I find it distressing how obnoxiously loud and arrogant many C++
fanatics are.

Things that I want in a development environment are, in order:

  1.  Implementation of a standard language, to the letter.
      Think C 5 implements a really good ANSI C.
      C++ is not a standard.  It's a moving target.
  2.  Language stability.
      C++ is changing all the time.  Count yourself lucky if
      your code still compiles next year.
  3.  Portability.
      The OOP stuff in Think C 5 is not really portable.
      Neither is C++.
  4.  Speed.
      The compiler has to be able to compile quickly.
      Note that there are human factors to speed.  Under
      thirty seconds, Under a minute, under ten minutes,
      under an hour, and less than ten hours (overnight)
      are targets.  MPW C++ misses anything under a minute.
      I could cope with a super-optimizer that took all
      night.
  5.  Error checking
      It should be able to perform strong type checking,
      catch all language errors, provide "lint" capabilities,
      and catch typical mistakes, such as "if (foo = bar) {..."
      Think C does much, but not all it could.
  6.  Good code quality.
      It should do what you expect.
  7.  Small code
      The code produced should be as small as possible.
      This means that objects can load faster.
      Small code is usually faster, anyway.
  8.  Fast code
      If producing fast code takes a long time, it
      should be optional.
  9.  Debugging.
      Symbolic source debugging, with asm hooks.  Breakpoints,
      good formatting, especially for structures, etc.
      When my app does something it shouldn't, the debugger
      shouldn't crash, and should let me do post crash
      analysis.  Think C has this.  I'm sure it could be
      improved, especially with OOP.  I just don't know how.
  10. Good documentation.
      Manuals should be free from error.  They should be
      easy to use for a relative beginner.  They should be
      easy to reference by a pro.  This is one of the
      harder parts.
  11. Good library support.
      The supplied libraries should enable me to make full
      use of the target hardware.  They should enable fast
      prototyping.  I find the Think C "C" library to be complete,
      flexible (I use ANSI-small, sometimes).  I find TCL
      to be good for prototyping & quick starting.  One thing
      it should be is more modular.  One should be able to
      use some of them independently of the others.  For
      example, I'd like to be able to use CStyleEditText without
      CPrinter.

Do I need C++?  Well, currently, I find it is harder to debug
than C.  The indirection is obfuscated.  It is too hard to track
down.  The "call by reference" syntax makes it more difficult to
tell if you are passing a pointer, a copy, or the original variable.

Stephen.
[e-mail]



- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  Suggestion to the Developers of Think C
Date: 2 Mar 92 22:20:07 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

>>That [stopping at first error] is the one "feature"
>>of Think C that I truly hate.
>>A logfile would free programmers from the "let's find the next error
>>and recompile" methodology/rut that Think C FORCES us into.

If you are porting from another platform, or from MPW, or even an
old version of Think C, having the list of errors might be
faster.  I just finished the compile portion of porting some
software that ran (runs) under Think C 3.0.  Here, having the
compiler grunge through all the files & generate a big list might
be a win.

BTW, the "prototype helper" was a big help.  I wish the user interface
on the "compare" utlitity was better.

Most of the stuff I do, however, is add a feature, a file, a header,
and recompile just those things.  Stop on the first error is better
here.

At work, I get alot of news read (and written), while MPW compiles -
even if there are no errors.  Now, compilers could be written that
are faster, even under MPW.  If a compiler goes from source to
object directly, rather than in multiple passes writing temp files,
it will be faster.  This could be done under MPW, it just isn't.
The Plan 9 people have said this about the UNIX enironment too.

Stephen.



- -------------------------

From: [e-mail] (John Andrews)
Subject:  Suggestion to the Developers of Think C
Organization: UIUC Center for Supercomputing Research and Development
Date: Tue, 3 Mar 92 01:48:18 GMT

[e-mail] (Stephen Uitti) writes:
> [Lots of stuff about C vs. C++]
>The "call by reference" syntax makes it more difficult to
>tell if you are passing a pointer, a copy, or the original variable.

>Stephen.
>[e-mail]

Stephen, I agree with much of your post, but I couldn't let this one go.
I find that it is not uncommon for me to change something from call by value
(CBV) to call by reference (CBR) because I discover I have to return a
modified value of something to the caller.  If a function has X call sites
and Y uses of a variable in the body, then C makes me change (X+Y+1) lines
of code, whereas C++ makes me change 1 if I change the variable from CBV to CBR.
Or, more to the point, I don't *care* if the thing is a pointer or not, I just
want to reference it!  The lack of true CBR is one my biggest problems with C.

--
John Andrews ([e-mail]) "He who dies with the shortest .sig, wins"
Graduate Research Assistant, Center for Supercomputing R&D, Urbana, IL



- -------------------------

From: [e-mail] (Glenn Austin)
Date: Mon, 2 Mar 92 18:10:44 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Paul Lucas) writes:
>     Also, remember the original Mac commercials?  Specifically, the
>     one with an IBM PC on a desk and then the hulking user-manual
>     crashing down next to it; then a Mac, will a thin booklet almost
>     floating down next to it?  Of course, the situation is reversed
>     when it comes to programming the thing (case in point: Inside
>     Macintosh I-VI plus the technotes--end-to-end, it's about s foot
>     thick).  In order to program the Mac (and even Apple has said
>     this), you're going to need OOP.

And the equivalent documentation to write in a graphic environment on the
PC takes an entire 3-shelf bookshelf.  Still sounds like a better deal to
me to work on the Mac...

I still haven't heard Apple say, "In order to program the Mac, you need
OOP."  I HAVE heard, "If you want your program to keep up with the latest
in Mac OS technology, you should write in MacApp."  IMHO, this is an entirely
different statement.  The first is a requirement, and the second a
recommendation.


===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================

- -------------------------

From: [e-mail] (Glenn Austin)
Date: Mon, 2 Mar 92 18:22:40 PST
Organization: The Pit Lane


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Brian Donnell) writes:
> Splitting the project into smaller files does not solve the problem, for Think
> C stops the entire "make" at the first file where the first error occurs.

Gee -- so does MPW!  In fact -- I've left a compile for lunch after changing
a debugging equate so that no more debugging statements are generated, only
to come back to find that somewhere, I enclosed a closing brace in my #if--#endif
pair, which now has generated more than a page of spurious errors and warnings.
It's real fun explaining to my boss why I'm wandering the halls because my
computer is now crunching code, and that I can't do anything anyway...

> Even considering the arguments that others have made about the effects of
> on the speed of compilation made by error recovery, Think C could at least
> try every file on a make so that I could see the first error from every file.
> What if I'm compiling 100 modules and there are no errors except on line 100
> of the third one?  I walk away expecting the compile to take about 30 minutes
> (pretty good - Think C wins high marks)...but come back to discover it failed
> after a minute and a half.  Grrr.

I have the same problem when I work on MPW at work -- the only difference
is that MPW takes 3 minutes to find the SAME BLOODY ERROR (at least!)  At
least I have a Magellan '040 in my IIci so that MPW now takes about a minute
to find the error...


===============================================================================
| Glenn L. Austin                | "Turn too soon, run out of room.           |
| Macintosh Wizard and           |    Turn too late, much better fate."       |
| Auto Racing Driver             |   -- Jim Russell Racing School Instructors |
| Usenet:  [e-mail] or [e-mail]    |
===============================================================================

- -------------------------

From: [e-mail] (Paul Lucas)
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 3 Mar 1992 00:15:44 GMT

In <[e-mail]> [e-mail] (Stephen Uitti) writes:

>Things that I want in a development environment are, in order:

>  1.  Implementation of a standard language, to the letter.
>      Think C 5 implements a really good ANSI C.
>      C++ is not a standard.  It's a moving target.

    If timetables were shifted slightly, say that C wasn't yet
    standardized, you're complaint about C++ would apply to C as
    well.

>  2.  Language stability.
>      C++ is changing all the time.  Count yourself lucky if
>      your code still compiles next year.

    This is an exaggeration.  The biggest change was from 1.2 to
    2.0; since 2.0, only "minor" semantics have changed; in 3.0 most
    stuff is an addition (e.g. templates).

>  4.  Speed.
>      The compiler has to be able to compile quickly.
>      Note that there are human factors to speed.  Under
>      thirty seconds, Under a minute, under ten minutes,
>      under an hour, and less than ten hours (overnight)
>      are targets.  MPW C++ misses anything under a minute.
>      I could cope with a super-optimizer that took all
>      night.

    This is not a comparison to MPW.  Just because Apple's C++
    implementation is slow doesn't mean that all C++ implementations
    are/will be slow.

>Do I need C++?  Well, currently, I find it is harder to debug
>than C.  The indirection is obfuscated.  It is too hard to track
>down.  The "call by reference" syntax makes it more difficult to
>tell if you are passing a pointer, a copy, or the original variable.

    Call-by-reference *ALWAYS* calls-by-reference; what's the
    problem?  Hence, it's always a pointer in disguise.  By the way,
    call-by-reference is nothing new; many languages have it and
    have had it for a while, e.g., Pascal.  Nobody complains about
    that.
- --
    - Paul J. Lucas                University of Illinois
      AT&T Bell Laboratories        at Urbana-Champaign
      Naperville, IL            [e-mail]

- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: 3 Mar 92 13:03:53

In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>  1.  Implementation of a standard language, to the letter.
>      Think C 5 implements a really good ANSI C.
>      C++ is not a standard.  It's a moving target.

... soon to be a standard, onlike the Think OOP extensions.

>  2.  Language stability.
>      C++ is changing all the time.  Count yourself lucky if
>      your code still compiles next year.

This is not true. C++ *is* changing, but you would have a hard time finding a
C++ program that compiled under an older version and wouldn't compile under a
newer one.

>  3.  Portability.
>      The OOP stuff in Think C 5 is not really portable.
>      Neither is C++.

MPW C++ has, of course, some extensions which are non-portable. It is, however,
possible to write portable object oriented programs in C++, which isn't
possible in Think C. (But portability is not that high on my list).

>  4.  Speed.
>      The compiler has to be able to compile quickly.
>      Note that there are human factors to speed.  Under
>      thirty seconds, Under a minute, under ten minutes,
>      under an hour, and less than ten hours (overnight)
>      are targets.  MPW C++ misses anything under a minute.
>      I could cope with a super-optimizer that took all
>      night.

True, but this has nothing to do with the language.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

- -------------------------

From: [e-mail] (Pete Gontier)
Date: Tue, 03 Mar 1992 00:09:20 -0500

 CT> From: Christopher Tate <[e-mail]>

 CT> Indeed; some people don't *want* C++.  I'm fully aware that that's a
 CT> heretical statement in some circles, but *expert* opinion is more divided
 CT> on C++ than many people realize.

Eiffel! Eiffel! Coming to an MPW near you next month or the month after!
(Does this make mine an expert opinion? :-)

 CT> Certainly it can be a powerful tool
 CT> for establishing maintainability or for designing a program structure,
 CT> but it's not really any "easier" to use OOP; it's a subtle skill that
 CT> some programmers are simply not comfortable with.

Well, that's not really much of an excuse, as long as the objects are
a bag on the side of a procedural language, like C++.

 CT> And [he says, climbing out on a limb] it's not necessarily the "wave of
 CT> the future" that so many people (both well- and ill-informed) seem to
 CT> think.

Maybe I'm stupid, but I have to wonder what else might be.

 CT> I'd like to have some of the CMarker functionality built into the
 CT> editor -- especially the little menu to pull down that gives you a
 CT> list of all functions in the document, in order to jump to them.

There's an app called MarkerMaker floating around on some of the pay services.
Supports "drag and drop" of entire folders. Free. I use it every day. Allows
you to make Command-Click-Hold sequences in source window title bars actually
useful, and without hacks. If this little app is not on sumex, it should be.
(I'd put it there, but there's this little problem with my network...)

 CT> I'd like to be able to edit generic text files without requiring a
 CT> project file to be open.

Suggested by many, rejected often. Turns out this is a big rewrite. Don't
ask me why, I just remember a THINKer posting that.

 CT> I'd *especially* like to search/replace in files that aren't in the
 CT> current project.

Dunno how the UI would work, but me too.

- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Tue, 3 Mar 1992 15:21:58 GMT

[e-mail] writes:
>[e-mail] (Paul Lucas) writes:
>>     ... the situation is reversed
>>     when it comes to programming the thing (case in point: Inside
>>     Macintosh I-VI plus the technotes--end-to-end, it's about s foot
>>     thick).

18 3/8", to be precise.

>And the equivalent documentation to write in a graphic environment on the
>PC takes an entire 3-shelf bookshelf.  Still sounds like a better deal to
>me to work on the Mac...

For example, the Microsoft Mouse programmer's book -- the technical work
that explains how to program with the mouse -- is as thick as IM4.
And don't think for a second that all your customers' mice will be
Microsoft-compatible.

My opinion;  I speak for myself.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.

- -------------------------

From: [e-mail] (Michael Hecht)
Date: 3 Mar 92 14:56:49 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail] writes:
>
> And to Brian: I don't normally have 100 files to recompile, because I'm working
> error by error, rather than making changes to 100 files and seeing if they
> worked out correctly.  I really think I get my code up and running faster
> because of it...

Dave, I think most of us work that way. But there are still occasions when
you can end up with an enormous number of files to recompile. For example,
say you change two files: you add a field to a structure in some header file
and you add some code to use that structure in some c file. But, you introduce
a syntax error into the c file. You hit Update and walk away. THINK C suddenly
has 100 files to recompile because of the changed header. Unfortunately,
everything stops when it gets to the c file with the syntax error.

Because of this, I've gotten into the habit of recompiling specific c files
that I've changed, before I do a big update. I'd prefer having an error log
that just lists the first error found in each unsuccessful compile.

The same thing can occur if you're working with a team of programmers. Someone
else's source code compiles just fine on their machine, but because of a
header file they forgot to update, your recompile of the 100 source files they
just checked in fails. Of course, a real multi-user programming environment
would help this situation immensely :-).

As for some of the other suggestions that have been floating around, if
Symantec doesn't have the resources to add everything we want, maybe they
could open up the THINK environment so we could add our own tools. Maybe
they could provide us with the format of a project file, or with a "Project
Manager" library of routines for access, or with a suite of AppleEvents for
manipulating them. Maybe they could make the various components of the
environment more modular, and communicate between them with AppleEvents, so
we could plug in replacements or enhancements for certain parts.

- --Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT

- -------------------------

From: [e-mail] (Ed Lai)
Date: 3 Mar 92 21:59:49 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Zach Kessin) writes:
>
>How about using apple-events to control the environment, you could use
>whatever editor you wanted, and have it tell think C to compile or
>link bring up the class browser. Also you could have think Pascal use
>the same apple-events so that you could use one editor with both.
>

It should be pointed out similar work has already been done on MPW. There
is an application called ToolServer that let you run any MPW tool through
Apple Event. You can also do it to MPW 3.3 except that getting the result
back is more difficult. THINK should do the same thing.

While we are on the subject of what THINK should do, the distinction
between a compiled language such as C/PASCAL and an interpreter language
such as BASIC is blurred, There is no reason why we cannot use it as a
scripting language where we keep the source file intact, but we can double
click on the source file directly to run the program.

/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS37-UP                                     */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi

- -------------------------

From: [e-mail] (Brian Donnell)
Date: 3 Mar 92 22:03:22 GMT
Organization: NASA/JSC

In article <[e-mail]>, [e-mail] writes:
> And to Brian: I don't normally have 100 files to recompile, because I'm working
> error by error, rather than making changes to 100 files and seeing if they
> worked out correctly.  I really think I get my code up and running faster
> because of it...
>

You can change just a few files and have this scenario bite you.  For example,
say I change one header (.h) file that all my source (.c) files depend on,
and assume I make no mistakes.  I also change one source file and make one
stupid syntax error that I do not notice.  Knowing that I have changed that
crucial header file, I start the compile and go down the hall to run another
errand.  Unfortunately, the make halts at the error in that bad source
file and all that multitasking effort was for naught.  Bleech.

Brian

- -------------------------

From: [e-mail] (Alain Roy)
Date: 3 Mar 92 22:25:48 GMT
Organization: University of Chicago Computing Organizations

In article <[e-mail]> [e-mail] (Paul Lucas) writes:
>In <[e-mail]> [e-mail] (Stephen Uitti) writes:
>
>    Call-by-reference *ALWAYS* calls-by-reference; what's the
>    problem?  Hence, it's always a pointer in disguise.  By the way,
>    call-by-reference is nothing new; many languages have it and
>    have had it for a while, e.g., Pascal.  Nobody complains about
>    that.
>--

I complain about it! What I complain about is not so much the idea
of call by reference, but the syntax of it. As you said, it's "a pointer
in disguise." When I'm working on a large project and I look at a function
call, I may not always remember that the call was call by reference unless
I use a pointer. And then a variable can be changed under my nose. This has
always been a gripe of mine about C++ and Pascal. When I pass something
by reference in C however, I use the & operator and then it is really
obvious to me. Call by reference just doesn't look different, and I wish
it did, to assist my fallible memory.

sorry, just one of my pet peeves.

>    - Paul J. Lucas                University of Illinois
>      AT&T Bell Laboratories        at Urbana-Champaign
>      Naperville, IL            [e-mail]

Alain Roy
[e-mail]

- -------------------------

From: [e-mail] (Paul Lucas)
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 4 Mar 1992 00:24:07 GMT

In <[e-mail]> [e-mail] (Alain Roy) writes:

>In article <[e-mail]> [e-mail] (Paul Lucas) writes:
>>In <[e-mail]> [e-mail] (Stephen Uitti) writes:
>>
>>    Call-by-reference *ALWAYS* calls-by-reference; what's the
>>    problem?  Hence, it's always a pointer in disguise.  By the way,
>>    call-by-reference is nothing new; many languages have it and
>>    have had it for a while, e.g., Pascal.  Nobody complains about
>>    that.
>>--

>I complain about it! What I complain about is not so much the idea
>of call by reference, but the syntax of it. As you said, it's "a pointer
>in disguise." When I'm working on a large project and I look at a function
>call, I may not always remember that the call was call by reference unless
>I use a pointer. And then a variable can be changed under my nose. This has
>always been a gripe of mine about C++ and Pascal. When I pass something
>by reference in C however, I use the & operator and then it is really
>obvious to me. Call by reference just doesn't look different, and I wish
>it did, to assist my fallible memory.

    That's why there are such things as const references.  If the
    programmers who wrote the function used const referneces, then
    there's no need for you to know, i.e., it's just an efficiency
    measure.

    References also have a couple of "cool" advantages like allowing
    an object to be an l-value and allow allowing functions to be
    "chained" together.

    If a function does alter it's arguments, then you can still use
    the (real) pointer notation.  I'm not sure, but I think that
    Bjarne advocates (advocated?) this last point.
- --
    - Paul J. Lucas                University of Illinois
      AT&T Bell Laboratories        at Urbana-Champaign
      Naperville, IL            [e-mail]

- -------------------------

From: [e-mail] (Pete Gontier)
Date: Tue, 03 Mar 1992 22:39:05 -0500

 GA> From: [e-mail] (Glenn Austin)

 GA> It's real fun explaining to my boss why I'm wandering the halls because
 GA> my computer is now crunching code, and that I can't do anything anyway...

Bosses are always convinced there's something you can do while your
compiler is running. As if you have all your code memorized and it's
just a matter of discipline to continue editing in your head.

Isn't there another group for complaining about one's boss? Oh well.
In a couple of weeks or so we'll have a real UseNet bridge and I'll start
reading it again.

- -------------------------

From: [e-mail] (David Spencer)
Date: Wed, 4 Mar 1992 13:45:48 GMT
Organization: PANIX Public Access Unix, NYC

In <[e-mail]> [e-mail] (Pete Gontier) writes:

> CT> I'd *especially* like to search/replace in files that aren't in the
> CT> current project.

>Dunno how the UI would work, but me too.

A dialog box with buttons for all the options constructs a command
line in an editable text box. You can select the files with a file
dialog (I love TC5's add-to-project dialog) or type the file names or
globbing pattern in the command line text box. For an example, check
out a/ux commandos.

David Spencer
[e-mail]


- -------------------------

From: [e-mail] (Pat Fortner @ PCB/N x1248)
Date: 4 Mar 92 19:52:50 GMT
Organization: engr

Many of the suggestions I've seen would be very helpful to me.  But one
I haven't seen mentioned yet is any sort of source code management
within Think C.  I am seriously considering buying the MPW shell simply
for Projector.  While my code is in the early stages of a new project,
files change rapidly and checking them in and out can be a nuisance.  But
when things begin to stabilize, checking source and header files in and
out, being able to name and recall past versions, create branches, etc
is something I sorely miss.

Pat

(PS Is there ANYTHING out there in MacLand other than Projector that does
this? )
- --
- ------------------------------------------------------------------------------
Patrick Fortner
Mentor Graphics Corporation
8005 SW Boeckman Road

- -------------------------

From: [e-mail] (Joe Francis)
Date: 4 Mar 92 23:22:59 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Alain Roy) writes:

> I complain about it! What I complain about is not so much the idea
> of call by reference, but the syntax of it. As you said, it's "a pointer
> in disguise." When I'm working on a large project and I look at a function
> call, I may not always remember that the call was call by reference unless
> I use a pointer. And then a variable can be changed under my nose. This has
> always been a gripe of mine about C++ and Pascal. When I pass something
> by reference in C however, I use the & operator and then it is really
> obvious to me. Call by reference just doesn't look different, and I wish
> it did, to assist my fallible memory.

I agree, but this is really only a problem in C++ when you are forced
to use someone elses code, and it uses references.  If you are writing
your own C++ code, folow this simple rule: DON'T USE REFERENCES!
References (for the reason you state) are more pain than gain except in
very specific circumstances (like defining the "+" operator for a
class, for instance).  And in those specific circumstances, it is easy
to remember that it you have a reference.  In Pascal, it's difficult to
avoid references.  In C++, it's easy.

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 6 Mar 92 20:00:47 GMT

I would like to see a few things about the environment automated.

The new settings dialog is huge.  Whenever I'm going from alpha to beta,
I always forget an option or two, and this requires a complete re-compile.
Same with going from beta to gold.  I would like very much to have a pop
up menu in the project dialog that specifies what stage the project is in,
and sets the options accordingly.  This way I wouldn't forget to turn off
the MacsBug names before creating a gold release.

I would like to see THINK C automatically handle SIZE and VERS resouces.
Seems like these are so dependent on the compile and stage that the
project is in that it doesn't make sense to have to exit out to ResEdit
to edit them.  If they were a part of the project file, I would be happy.

Finally, I would really like the C debugger to be as capable as LightsBug
is in Pascal.  C is a lower level language than Pascal, yet it has none
(or very few) of the low-level machine-specific features of LightsBug.
I find it interesting that the C debugger would be at home on any machine--
you could use its interface with no changes on anything from PC to an Iris.
This does say that perhaps it doesn't embrace the Macintosh as well as it
could.

Support for MPW tools and automatic conversion of string literals in your
source file into STR resources would also be great.

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 6 Mar 92 20:34:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] writes:
> There hasn't been any C++ 'features' that I have needed and haven't been able
> to get along without.  C++ seriously munges programming style more and more,
> especially letting you declare vars anywhere in your code (the reason for
> putting them at the top of a fn was readibility, and boy is readibility
> losing it in c++!).

Well, something like
for(int i; i == 10; i++)

is far more readable than having the i declared pages of text before the
for loop, or what...


> Who is the market?  I don't need full C++.  If you are serious about OOP,
> you'll be using SmallTalk or CLOS (real object systems) and not a language
> that was force-fed object ideas.  The market wants better OOP development
> tools, languages, etc.  C++ will probably go away, but I'm willing to bet
> we'll see the next gereation of languages like CLOS for a long time yet.

I'm a DLE (see .signature below), however for the moment we don't have the
possible development platforms to effectively write horizontal applications
using CLOS or SmallTalk. This will happen, sooner or later anyway. So C++
is unfortunately a viable alternative just now, mostly because it does not
produce any penalties concerning the final binary. Anyway,I also hope that
C++ is the last of the dying breed of static and non-orthogonal languages.

> The entire Symantec Languages Group should be commended for their work.  They
> are a tiny group for what they are handling, and they are effectively
> competing against Apple (MPW).

I hope there's no real competition between MPW and Think, they both have
their own market shares, and that's a good thing for both companies.

Cheers,
Kent

- --
Kent Sandvik - Apple DTS  - Dynamic Language Evangelist
[e-mail]
All opinions expressed are my own, and not related to any company or
organization.
Have fun!

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 7 Mar 92 04:27:36 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>> The entire Symantec Languages Group should be commended for their work.  They
>> are a tiny group for what they are handling, and they are effectively
>> competing against Apple (MPW).
>
>I hope there's no real competition between MPW and Think, they both have
>their own market shares, and that's a good thing for both companies.

There's a piece of apocrypha that goes like this: A couple of years ago, a
manager at Apple in charge of either the MPW group or tools & languages
in general (I don't recall which, exactly) once reportedly said to the
MPW group: "THINK is not our competition. NeXT is our competition."

I couldn't agree more. Both companies produce tools that help make software.
Software sells CPUs. This is good, because CPU sales lead to software sales,
which in turn keeps us all gainfully employed. MPW and the THINK products
complement each other nicely, and any remotely serious developer should
have both.

R.


- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group

+++++++++++++++++++++++++++

From: [e-mail] (Howard Cash)
Date: Sun, 08 Mar 92 11:33:22 EST
Organization: Cognitive Science Machine Intelligence Lab, Univ. of Michigan

In article <[e-mail]> [e-mail]
>     (Donald T. Major) writes:
>In article <[e-mail]>,
>     [e-mail] (Brian Donnell) writes:
>[stuff deleted]
>|> I would also like Think C to get way from this 'stop on the first error'
>|> nonsense.  Write it all out to a log file - so that I can leave a long
>|> compile unattended w/o being 99.999% sure that there will be no errors.
>
>No, no, no (:-))!  I actually LIKE the way the compiler works, as far
>as stopping on the errors...

Wow!  I've NEVER heard anyone say that they liked the fact that ThinkC
compiles stop on every error!  Since there is at least one person who
seems to like this "feature" (I presume it is because of a perception
that this is where the compiler gets its speed) how about this:  If
you are compiling a big project and find an error in a file, at LEAST
go on to the next file and compile it, if possible.  If I want to compile
62 .c files in a project, I usually run it overnight.  If I failed to
terminate a comment in file #6, I'd love to have the 61 OTHER files
run through the compiler, even if the compiler doesn't check the naughty
file #6 for any other (subsequent) errors.

- -Hobie

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 9 Mar 1992 09:20:13 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>Well, something like
>for(int i; i == 10; i++)
>
>is far more readable than having the i declared pages of text before the
>for loop, or what...

Actually, this example is not extremely convincing, since it interacts with the
semantics of a C for loop in an unfortunate and counterintuitive way (Hint: try

for (int i = 0; i<10; i++)
   do_something;

for (int i = 0; i<15; i++)
   do_something_else;

and your compiler will say something unfriendly to you).

I like C++, but not because of this feature.

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 9 Mar 92 01:31:40 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Stephen
Uitti) writes:
> I find it distressing how obnoxiously loud and arrogant many C++
> fanatics are.

Well, after using C++ since 1986 I'm still no C++ fanatic, however
we have to face the realities of software development, and until
we have better dynamic object oriented language implementations most
serious developers are starting to use C++ for their big projects.

>   1.  Implementation of a standard language, to the letter.
>       Think C 5 implements a really good ANSI C.
>       C++ is not a standard.  It's a moving target.

Not anymore, after the Cfront 2.0 shakeout. I would not worry about
moving C++ code between environments, as long as they are written with
at least Cfront 2.0 features. And if someone complains about missing
templates or exception handling, there are always ways to get these features
working with a compiler that does not have 'em (i.e. Rational template
pre-processor, MacApp exception handling libraries).

>   2.  Language stability.
>       C++ is changing all the time.  Count yourself lucky if
>       your code still compiles next year.

I don't think this valid at all. As mentioned earlier, I would not
worry about this at all.

>   3.  Portability.
>       The OOP stuff in Think C 5 is not really portable.
>       Neither is C++.

Sorry, not true, as most C++ compilers so far has been implemented
using Cfront from AT&T, it's been fairly trivial to move code between
platforms. Also the ARM book stabilized the feature list, so most if
not all C++ vendors try to conform to ARM until the ANSI standard is
ready.

>   4.  Speed.
>       The compiler has to be able to compile quickly.
>       Note that there are human factors to speed.  Under
>       thirty seconds, Under a minute, under ten minutes,
>       under an hour, and less than ten hours (overnight)
>       are targets.  MPW C++ misses anything under a minute.
>       I could cope with a super-optimizer that took all
>       night.

The language has nothing to do with implementations...

>   5.  Error checking
>       It should be able to perform strong type checking,
>       catch all language errors, provide "lint" capabilities,
>       and catch typical mistakes, such as "if (foo = bar) {..."
>       Think C does much, but not all it could.

Here's actually a case where C++ has far better error checking. However
it also slows down the parsing, so you always loose something when you
gain something.

>   9.  Debugging.
>       Symbolic source debugging, with asm hooks.  Breakpoints,
>       good formatting, especially for structures, etc.
>       When my app does something it shouldn't, the debugger
>       shouldn't crash, and should let me do post crash
>       analysis.  Think C has this.  I'm sure it could be
>       improved, especially with OOP.  I just don't know how.

This is also an implementation issue concerning debuggers. In the
Mac world, SADE, SourceBug and Jasik Debugger all understand the
C++ object extensions. Also MacsBug and TMON are able to unmangle the mangled
C++ names.

> Do I need C++?  Well, currently, I find it is harder to debug
> than C.  The indirection is obfuscated.  It is too hard to track
> down.  The "call by reference" syntax makes it more difficult to
> tell if you are passing a pointer, a copy, or the original variable.


I find it easier to debug, mostly because data abstraction gives me
a nice way to narrow down problem states, something which is harder in a
structured program with no abstraction barriers.

Call-by-reference is Pascal VAR style, and many consider this to be more
easier to understand than C pointers (which is easy to grasp for an
assembly programmer, but harder for a pure high-level programmer never
exposed to low level addressing schemes).

Cheers,
Kent

- --
Kent Sandvik - Apple DTS  - Dynamic Language Evangelist
[e-mail]
All opinions expressed are my own, and not related to any company or
organization.
Happy, happy, joy, joy!

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Wed, 11 Mar 1992 19:32:06 GMT

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Stephen
>Uitti) writes:
>>   1.  Implementation of a standard language, to the letter.
>>       Think C 5 implements a really good ANSI C.
>>       C++ is not a standard.  It's a moving target.
>
>Not anymore, after the Cfront 2.0 shakeout. I would not worry about
>moving C++ code between environments, as long as they are written with
>at least Cfront 2.0 features. And if someone complains about missing
>templates or exception handling, there are always ways to get these features
>working with a compiler that does not have 'em (i.e. Rational template
>pre-processor, MacApp exception handling libraries).

At some point, templates and exception handling will be
available.  Until then, one can use various non-portable tricks
as mentioned.  Not every environment has these tricks available.
When templates and exceptions become available, there will be
environments that won't get upgraded, for whatever reasons (the
compiler didn't use CFront, the company went out of business, etc.).

And not all compilers use Cfront.

>>   4.  Speed.
>The language has nothing to do with implementations...

In the real world it does.  Either you use Cfront and you have
parsing that is no worse than anyone else's, but slow, or you
do your own, integrated into your compiler, and it is faster.
I want a compiler that is faster.  That's why I like Think C.

>>   5.  Error checking
>>       It should be able to perform strong type checking,
>>       catch all language errors, provide "lint" capabilities,
>>       and catch typical mistakes, such as "if (foo = bar) {..."
>>       Think C does much, but not all it could.

>Here's actually a case where C++ has far better error checking. However
>it also slows down the parsing, so you always loose something when you
>gain something.

The trouble is that C++ adds all sorts of new complications to
the language.  For every error that might have been common in
C that C++ fixed, it introduces several new ones.

>> Do I need C++?  Well, currently, I find it is harder to debug
>> than C.  The indirection is obfuscated.  It is too hard to track
>> down.  The "call by reference" syntax makes it more difficult to
>> tell if you are passing a pointer, a copy, or the original variable.
>
>I find it easier to debug, mostly because data abstraction gives me
>a nice way to narrow down problem states, something which is harder in a
>structured program with no abstraction barriers.

What I meant by indirection is mostly the construction of
objects.  This is especially true if an object has a long
ancestry.  I spent an hour tracing through just the construction
of a single object the other day in an attempt to track down a
bug.  I eventually found the bug.  However, it took so long to
slog through it that I missed what I was looking for.  It wasn't
until the next day that I remembered the critical part that went
wrong and was able to look at the sources again to determine what
really happened.  Even that was painful, due to the fact that
each object has several constructors.  Which one was being
called?  By eye, there isn't always a match.  Is there some type
conversion going on behind my back?  It's bad enough that short
can be automatically promoted to a long.  Now a FurbleWart can be
automatically promoted to a BlinderSnatch.  Sometimes you have to
use the debugger just to find out which constructor is called.  I
don't want anything going on behind my back.  I want it all out
in the daylight.  That way I have a prayer of debugging things
by inspection.

>Call-by-reference is Pascal VAR style, and many consider this to be more
>easier to understand than C pointers (which is easy to grasp for an
>assembly programmer, but harder for a pure high-level programmer never
>exposed to low level addressing schemes).

I'm not saying that VAR style parameters aren't easier to write,
I'm saying that they are harder to read.  The semantics aren't
clear.  Is this parameter modified?  Can it be?  If the answer is
"no" (as is clearer in plain C), then you can look elsewhere
quickly.  If the answer is "yes", you must trace through the
called routine for an answer.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Thu, 12 Mar 1992 10:06:36 GMT

In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>>In article <[e-mail]>, [e-mail] (Stephen
>>Uitti) writes:
>>>   1.  Implementation of a standard language, to the letter.
>>>       Think C 5 implements a really good ANSI C.
>>>       C++ is not a standard.  It's a moving target.
>>
>>Not anymore, after the Cfront 2.0 shakeout. I would not worry about
>>moving C++ code between environments, as long as they are written with
>>at least Cfront 2.0 features. And if someone complains about missing
>>templates or exception handling, there are always ways to get these features
>>working with a compiler that does not have 'em (i.e. Rational template
>>pre-processor, MacApp exception handling libraries).
>
>At some point, templates and exception handling will be
>available.  Until then, one can use various non-portable tricks
>as mentioned.  Not every environment has these tricks available.
>When templates and exceptions become available, there will be
>environments that won't get upgraded, for whatever reasons (the
>compiler didn't use CFront, the company went out of business, etc.).

Nobody except Symantec supports the Think C extensions, either. If you don't
wnat to use template and exception "tricks" (and not all of them are
nonportable), you don't have to.

>And not all compilers use Cfront.
>
>>>   4.  Speed.
>>The language has nothing to do with implementations...
>
>In the real world it does.  Either you use Cfront and you have
>parsing that is no worse than anyone else's, but slow, or you
>do your own, integrated into your compiler, and it is faster.
>I want a compiler that is faster.  That's why I like Think C.

As you said above, not all compilers use CFront.

>>Here's actually a case where C++ has far better error checking. However
>>it also slows down the parsing, so you always loose something when you
>>gain something.
>
>The trouble is that C++ adds all sorts of new complications to
>the language.  For every error that might have been common in
>C that C++ fixed, it introduces several new ones.

Such as ?

>  It wasn't
>until the next day that I remembered the critical part that went
>wrong and was able to look at the sources again to determine what
>really happened.  Even that was painful, due to the fact that
>each object has several constructors.  Which one was being
>called?  By eye, there isn't always a match.  Is there some type
>conversion going on behind my back?  It's bad enough that short
>can be automatically promoted to a long.  Now a FurbleWart can be
>automatically promoted to a BlinderSnatch.  Sometimes you have to
>use the debugger just to find out which constructor is called.  I
>don't want anything going on behind my back.

Nobody forces you to use these constructs, and some of us find them very
convenient.

>I'm not saying that VAR style parameters aren't easier to write,
>I'm saying that they are harder to read.  The semantics aren't
>clear.  Is this parameter modified?  Can it be?  If the answer is
>"no" (as is clearer in plain C), then you can look elsewhere
>quickly.  If the answer is "yes", you must trace through the
>called routine for an answer.

A question of discipline. In C++ you can distinguish cases very nicely:

a(Foo x)      //    Won't modfify it
a(Foo & x)      //    Will modify
a(const Foo & x)  //    Won't modify, just passed as areference for speed

You can't distinguish cases 2 and 3 in Pascal, and you couldn't in K&R C.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "There once was an Age of Reason, but we've progressed beyond it."
                                   -- Ayn Rand, _Atlas Shrugged_

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Uitti)
Date: 12 Mar 92 18:20:44 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <[e-mail]> [e-mail] (Matthias Ulrich Neeracher) writes:
>In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>>In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>>>In article <[e-mail]>, [e-mail] (Stephen
>>>Uitti) writes:
>>>Here's actually a case where C++ has far better error checking. However
>>>it also slows down the parsing, so you always loose something when you
>>>gain something.
>>
>>The trouble is that C++ adds all sorts of new complications to
>>the language.  For every error that might have been common in
>>C that C++ fixed, it introduces several new ones.
>
>Such as ?

Such as reference parameters.

>>I'm not saying that VAR style parameters aren't easier to write,
>>I'm saying that they are harder to read.  The semantics aren't
>>clear.  Is this parameter modified?  Can it be?  If the answer is
>>"no" (as is clearer in plain C), then you can look elsewhere
>>quickly.  If the answer is "yes", you must trace through the
>>called routine for an answer.
>
>A question of discipline.

Not if I'm not writing the code.  I have no control over the
code other people on the project write or wrote.

>In C++ you can distinguish cases very nicely:
>a(Foo x)      //    Won't modfify it
>a(Foo & x)      //    Will modify
>a(const Foo & x)  //    Won't modify, just passed as areference for speed
>
>You can't distinguish cases 2 and 3 in Pascal, and you couldn't in K&R C.

Those are prototypes for the function, not calls.  This is
a call:

    Foo x;    // a variable.
    a(x);    // a call.  What does it do?
        // it might be call-by reference
        // it might be call by copy
    a(&x);    // it's call by reference.

In C, you'd say

    struct Foo x;

    a(&x);    /* pass a pointer to the struct */
    a(x);    /* pass a copy of the struct */
        /* there is no call by reference, so
         * the above calls are unambiguous.
         * I don't have to look up the prototype.
         * In straight C, there will only be one.
         */

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Date: 13 Mar 92 09:33:04 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>In article <[e-mail]> [e-mail] (Matthias Ulrich Neeracher) writes:
>>In article <[e-mail]> [e-mail] (Stephen Uitti) writes:
>>>The trouble is that C++ adds all sorts of new complications to
>>>the language.  For every error that might have been common in
>>>C that C++ fixed, it introduces several new ones.
>>
>>Such as ?
>
>Such as reference parameters.

Reference parameters are *not8 an error. See below.

>>>I'm not saying that VAR style parameters aren't easier to write,
>>>I'm saying that they are harder to read.  The semantics aren't
>>>clear.  Is this parameter modified?  Can it be?  If the answer is
>>>"no" (as is clearer in plain C), then you can look elsewhere
>>>quickly.  If the answer is "yes", you must trace through the
>>>called routine for an answer.
>>
>>A question of discipline.
>
>Not if I'm not writing the code.  I have no control over the
>code other people on the project write or wrote.

No programming language can prevent people from writing bad code. It can merely
encourage them to write good code.

>>In C++ you can distinguish cases very nicely:
>>a(Foo x)      //    Won't modfify it
>>a(Foo & x)      //    Will modify
>>a(const Foo & x)  //    Won't modify, just passed as areference for speed
>>
>>You can't distinguish cases 2 and 3 in Pascal, and you couldn't in K&R C.
>
>Those are prototypes for the function, not calls.  This is
>a call:
>
>    Foo x;    // a variable.
>    a(x);    // a call.  What does it do?
>        // it might be call-by reference
>        // it might be call by copy
>    a(&x);    // it's call by reference.
>
>In C, you'd say
>
>    struct Foo x;
>
>    a(&x);    /* pass a pointer to the struct */
>    a(x);    /* pass a copy of the struct */
>        /* there is no call by reference, so
>         * the above calls are unambiguous.
>         * I don't have to look up the prototype.
>         * In straight C, there will only be one.
>         */

But this is not strictly true:

- - a() might be a preprocessor macro
- - x could be an array
- - x could be a pointer or contain a pointer to a structure which is modified.
  Last time I checked, C had no deep copy semantics.
- - &x could be merely a variable passed by reference for *speed*, not to modify
  it. There are indeed a few C++ proponents who argue that call by reference
  should only be used for such cases.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "No, what he didn't like about heroes was that they were usually
    suicidally gloomy when sober and homicidally insane when drunk."
                          -- Terry Pratchett, _The Colour of Magic_

+++++++++++++++++++++++++++

From: [e-mail] (Roy Lovejoy)
Date: 10 Mar 92 20:20:17 GMT
Organization: Adept Solutions

In article <[e-mail]> [e-mail] (Rich Siegel)
writes:
> There's a piece of apocrypha that goes like this: A couple of years ago, a
> manager at Apple in charge of either the MPW group or tools & languages
> in general (I don't recall which, exactly) once reportedly said to the
> MPW group: "THINK is not our competition. NeXT is our competition."
>
> <<OTHER STUFF>>
> -----------------------------------------------------------------------
> Rich Siegel                              Internet: [e-mail]
> Senior Software Engineer                 Applelink: SIEGEL
> Symantec Languages Group

- --

But with NeXTstep running on a '486, it WILL be running on a Mac soon...
Hmmmm. perhaps we might be able to run any OS on any machine, thus better
productivity on one platform may lead to increased sales on another..
Something to think about.

- -----------------+--------------------------------------------------
Roy Lovejoy      | internet:  [e-mail]
Head RGB Guy     | AppleLink: adept
Adept Solutions  | CIS:       72447,1447
                 | dual certified developer: NeXT & Apple ;)
- -----------------+--------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Brian Donnell)
Date: 13 Mar 92 20:26:28 GMT
Organization: NASA/JSC

Could we please take all the C++ stuff that has been in this thread and move
it over to comp.lang.c++?

Thanks.
Brian Donnell
NASA/JSC

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 Mar 92 21:24:40 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Matthias Ulrich
Neeracher) writes:
>
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> >Well, something like
> >for(int i; i == 10; i++)
> >
> >is far more readable than having the i declared pages of text before the
> >for loop, or what...
>
> Actually, this example is not extremely convincing, since it interacts with
the
> semantics of a C for loop in an unfortunate and counterintuitive way (Hint:
try
>
> for (int i = 0; i<10; i++)
>    do_something;
>
> for (int i = 0; i<15; i++)
>    do_something_else;
>
> and your compiler will say something unfriendly to you).
>
> I like C++, but not because of this feature.

I guess we're into the issue of variable scope, and yes in that sense
the i will be valid till the end of the block (I assume we are talking
about nested for statements).

However there are many times I write code where I declare a temp variable
or instance of a class, and I'm sure it will not be used after the construct
itself, and this is the case where declaration 'on-the-flight' is both
useful and easier to read code-wise. So I don't think this is one of the
C++ issues that stink :-). The things that are brain-damaged has to do
with the non-orthogonality of the language itself. For instance name
clashing due to lack of module/package support will cause a lot of screaming
during big projects.

Cheers,
Kent
- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are not private, and not owned by any company,
organization or group. Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 20 Mar 92 14:05:09 GMT
Organization: The Portal System (TM)

> Indeed; some people don't *want* C++.  I'm fully aware that that's a
> heretical statement in some circles, but *expert* opinion is more divided
> on C++ than many people realize.  Certainly it can be a powerful tool
> for establishing maintainability or for designing a program structure,
> but it's not really any "easier" to use OOP; it's a subtle skill that
> some programmers are simply not comfortable with.  It's not their style.
> And [he says, climbing out on a limb] it's not necessarily the "wave of
> the future" that so many people (both well- and ill-informed) seem to
> think.

Indeed, some of us use C as a system programming language.  C++ is much
harder to use for this, since the runtime support for the language is
more complicated.  Dynamic allocation of objects is fine, but my device
driver interrupt routine might be running at a time when it is not allowed!
C is easier to use in glorified-assembler mode, which is what we device
driver writers want.

I hope that if Symantec does offer a C++ someday, they also keep C available,
either by keeping the products separate, or by offering C++ as a preprocessor
for Think C.

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 20 Mar 92 14:09:24 GMT
Organization: The Portal System (TM)

>    Then you haven't really tried to use C++.  No language makes
>    programmers write "munged" programs--programmers write "munged"
>    programs.  You can write truly awful, impossible-to-read, and

OK, lets see you write a non-munged program of reasonable size in TECO.

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 20 Mar 92 14:32:27 GMT
Organization: The Portal System (TM)

> Dave, I think most of us work that way. But there are still occasions when
> you can end up with an enormous number of files to recompile. For example,
> say you change two files: you add a field to a structure in some header file
> and you add some code to use that structure in some c file. But, you introduce
> a syntax error into the c file. You hit Update and walk away. THINK C suddenly
> has 100 files to recompile because of the changed header. Unfortunately,
> everything stops when it gets to the c file with the syntax error.

Perhaps Think C should keep track of why it needs to recompile a source file.
Recompilation could then be ordered to be likely to hit errors quickly:

    0. Compile any new source files.

    1. Compile files whose source has changed and that also include
    one or more changed header files.

    2. Find the smallest set of C files (smallest means least
    size) that include all the changed header files not included in
    files from steps 0 or 1.  Compile these.

    3. Compile any changed C files not already dealt with above.

    4. Compile anything else that needs to be recompiled.

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Mon, 23 Mar 1992 14:12:22 GMT

In article <[e-mail]> [e-mail] (Tim W Smith) writes:
>Indeed, some of us use C as a system programming language.  C++ is much
>harder to use for this, since the runtime support for the language is
>more complicated.  Dynamic allocation of objects is fine, but my device
>driver interrupt routine might be running at a time when it is not allowed!
>C is easier to use in glorified-assembler mode, which is what we device
>driver writers want.
>
>I hope that if Symantec does offer a C++ someday, they also keep C available,
>either by keeping the products separate, or by offering C++ as a preprocessor
>for Think C.

I don't really understand what your problem is. The changes required to make a
reasonably written ANSI C program compile under C++ are, to my knowledge,
minimal (Bracketing prototypes with extern "C", any other problems ?).

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "Have you heard of the new Cambridge compilers ? They distribute
    gear-wear much more evenly"
        -- William Gibson/Bruce Sterling, _The Difference Engine_


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 23 Mar 92 18:24:56 GMT
Organization: MacDTS Mongols


It is hilarious that I (a dynamic language evangelist) am
supporting C++, anyway...

In article <[e-mail]>, [e-mail] (Stephen
Uitti) writes:
>
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> >>   4.  Speed.
> >The language has nothing to do with implementations...
> In the real world it does.  Either you use Cfront and you have
> parsing that is no worse than anyone else's, but slow, or you
> do your own, integrated into your compiler, and it is faster.
> I want a compiler that is faster.  That's why I like Think C.

No, we have a language spec, and a design, they are usually separate.
Borland managed to make a fast C++ compiler, AT&T didn't.

> >Here's actually a case where C++ has far better error checking. However
> >it also slows down the parsing, so you always loose something when you
> >gain something.
>
> The trouble is that C++ adds all sorts of new complications to
> the language.  For every error that might have been common in
> C that C++ fixed, it introduces several new ones.

It is true that C++ tried to eliminate many of the old C problems.
And yes, by adding new features you will get new errors. But I still
don't see the logic - by including new features you will certainly
get new problems. However in the C++ case at least the design took
into consideration semantical issues with each new feature
(at least they tried...).

> What I meant by indirection is mostly the construction of
> objects.  This is especially true if an object has a long
> ancestry.  I spent an hour tracing through just the construction
> of a single object the other day in an attempt to track down a
> bug.  I eventually found the bug.  However, it took so long to
> slog through it that I missed what I was looking for.  It wasn't
> until the next day that I remembered the critical part that went
> wrong and was able to look at the sources again to determine what
> really happened.  Even that was painful, due to the fact that
> each object has several constructors.  Which one was being
> called?  By eye, there isn't always a match.  Is there some type
> conversion going on behind my back?  It's bad enough that short
> can be automatically promoted to a long.  Now a FurbleWart can be
> automatically promoted to a BlinderSnatch.  Sometimes you have to
> use the debugger just to find out which constructor is called.  I
> don't want anything going on behind my back.  I want it all out
> in the daylight.  That way I have a prayer of debugging things
> by inspection.

I don't see the difference between constructors generated by
a compiler, and linking libraries which call other functions behind
the programmer's back. It's really a small difference. However in the
case of data abstraction you could eliminate factors down to one main
thread, in the case of functional programming you have to take into
account usually the whole function calling flow, and that could sometimes
be really tricky.

> >Call-by-reference is Pascal VAR style, and many consider this to be more
> >easier to understand than C pointers (which is easy to grasp for an
> >assembly programmer, but harder for a pure high-level programmer never
> >exposed to low level addressing schemes).
>
> I'm not saying that VAR style parameters aren't easier to write,
> I'm saying that they are harder to read.  The semantics aren't
> clear.  Is this parameter modified?  Can it be?  If the answer is
> "no" (as is clearer in plain C), then you can look elsewhere
> quickly.  If the answer is "yes", you must trace through the
> called routine for an answer.

They are as hard to read as pointer syntax.

Cheers,
Kent

- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are private, and not owned by any company,
organization or group. Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 25 Mar 92 20:04:34 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Matthias Ulrich
Neeracher) writes:
> I don't really understand what your problem is. The changes required to make a
> reasonably written ANSI C program compile under C++ are, to my knowledge,
> minimal (Bracketing prototypes with extern "C", any other problems ?).

ARM, page 403, lists the differences between C++ and ANSI C.

Kent

- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are not private, and not owned by any company,
organization or group. Happy happy, joy joy!

---------------------------

End of C.S.M.P. Digest
**********************